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Abstract 


This document describes an architecture for describing Simple Network 


Management Protocol (SNMP) Management Frameworks. The architecture 
is designed to be modular to allow the evolution of the SNMP protocol 
standards over time. The major portions of the architecture are an 


SNMP engine containing a Message Processing Subsystem, a Security 
Subsystem and an Access Control Subsystem, and possibly multiple SNMP 
applications which provide specific functional processing of 
management data. This document obsoletes RFC 2571. 


Table of Contents 


TL MERE ROGUCTE OA A A A A Se oes See A E de Wks 4 
A OVO LOW: Bisa bed Us Oh cP Gash  A ania ey gu svar e ene A 4 
SN A a a er ee a a wast gee sto toh 5 
did, Goars of this Architecture- y n as yaaa E a gee lose aaa ii Na 6 
1.4. Security Requirements of this Architecture ................ 6 
Ass Design- DecrsionS ns raaes A a ws deltas Sl E a 8 
2. Docümentation Overview esise es 10 
Des Lo DOCUMENT. ROAGMAD a cee Sue ees: aS 11 
2.24- Applicability Statement A elbd are been es 11 


Harrington, et al. Standards Track [Page 1] 


RFC 341 


0 J00ds W 


.9. 


ES ss ss ss YA AY WYw www WWW WWWWVWWWWVWWVWWWWWWWWWNNNNNNNNNNNNDNN 
Ss ss Y WYwWWNNNNA RR SR PR RI ppp PE 


PRPPrPP Pp 
. 


1 


.10. 
Ls 


1 
1 
1 
1 
1 
a 
1 
al 
2 
2 
3 
3 
3 


elg 
aos 
de 


edis 
DA 
de 
Abstract Service Interfaces 
Dispatcher Primitives 
Generate Outgoing Request or Notification ............... 
Process Incoming Request or Notification PDU ............ 
Generate Outgoing Response 
Process Incoming Response PDU 
Registering Responsibility for Handling SNMP PDUs ....... 


UO AUNE 


Architecture for SNMP Management Frameworks 


Coexistence and Transition 
Transport Mappings 
Message Processing 


SECA a Mir T A E E E A E E S E EEE EA E ET 
ACCESS: “CONG LOM, in A ot den S aA A a E See's 


Protocol Operations 


Applications. Sae des e e a a a a aoa a a E a r bee el te ears, ate a 


Structure of Management Information 
Textual Conventions 
Conformance Statements 
Management Information Base Modules 
.1. SNMP Instrumentation MIBs 
SNMP Framework Documents 

Elements of the Architecture 
The Naming of Entities 
SNMP -engine «soc ase oie tee snee a pe Bee So a Sus aiie eos 


snmpEngineID 


BR Ss YU NN PR 


Access Control 


.1. SNMP Manager 


Dispatcher a dl ld 
Message Processing Subsystem 
.1. Message Processing Model 
Security Subsystem 
.1. Security Model 
.2. Security Protocol 
Subsystem ......... 
.1. Access Control Model 
APPI TCA t ion A A A a 


¿Lis SNMP AGEN Ge eii a ts id a de 
The Naming of Identities 
BRINCIDAL at A ln a RE AR 
SE CURT CY NAM coches A ie ds ei an 
Model-dependent security ID 
The Naming of Management Information 
.1. An SNMP Context 

.2. contextEnginelD 

ls CON ESAEN AMO 2. cette wee of A A aA at S 
v4: 


SCODCOPDUL Ti rd St geese eet 


Other Constructs 


securityLevel 


Harrington, et al. 


maxSizeResponseScopedPDU 
Local Configuration Datastore 


Standards Track 


[Page 


December 2002 


RFC 3411 Architecture for SNMP Management Frameworks December 2002 


4.2. Message Processing Subsystem Primitives ................... 33 
4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 33 
4.2.2. Prepare an Outgoing SNMP Response Message +...ooooooooo... 34 
4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 35 
4.3. Access Control Subsystem Primitives .....o.o.ooooooooooo ooo... 30 
44:5. ¡Security Subsystem BrErmitives” etica la a e ai 36 
4.4.1. Generate a Request or Notification Message .............. 36 
4.4.:2-¢ PEOCESS: Incoming Message: erstes desa 36 
4.4.3. Generate a Response Message +..o.ooooooooooooooooo crono... 37 
Ars COMMON: PELMECIEVES A A A Tenia RE 37 
4.5.1. Release State Reference Information .....o.oooooooooooo.... 37 
4S On SECENALTO Dragrams ii A aa 38 
4.6.1. Command Generator or Notification Originator ............ 38 
4.6.2. Scenario Diagram for a Command Responder Application .... 39 
5. Managed Object Definitions for SNMP Management Frameworks ... 40 
O: LANA: -Gonsaderations ec a ds She a eee 51 
Ge La: Securtty Models. -man ate sigh aE ena E Ae Tes SD E E E eee ad ooo ao alee 51 
6.2. Message Processing Models .....ooooooooooooooooonon ee ene 51 
6.. 3:5 SHMPENGANE TD FO Mats sd fy ago tl a AIS a 52 
Jee nt Sd: Leetuad Property: ii cido a 52 
Sx ACKNOWLEAGEMENTS: a aaa aia 52 
9%. "SECUrTEY Considerations a a a ace eter ee 54 
LO References Ses ci ect eee aes ee Bs sere tet ave isle, Sop gets ig tell ote infect 54 
10 Normative: “References: doras aes a a Loa Se a aed ts 54 
10 Informative: Referentes reige his eae a aE aes Ree ee Pes 56 
A. Guidelines for Model Designers Vecinos a eee es 57 
A.l. Security Model Design Requirements ....o.o.ooooooooooooooooo.. 57 
Ad ds DAE OCOGS. en ss ts ds 57 
Arles ¡Security PROCESSING wi A oi b a oe ee EO S 58 
A.1.3. Validate the security-stamp in a received message ....... 59 
Aid do Security MIBS o A a a ade boi 59 
AL Cached Security Data ES ia ve Ge 59 
A.2. Message Processing Model Design Requirements .............. 60 
A.2.1. Receiving an SNMP Message from the Network .............. 60 
A.2.2. Sending an SNMP Message to the Network .................. 60 
A.3. Application Design RequirementS ......oooooooooooooooooo.o.. 61 
A.3.1. Applications that Initiate Messages ..................-2.. 61 
A.3.2. Applications that Receive Responses +....ooooooooooooooo.o.. 62 
A.3.3. Applications that Receive Asynchronous Messages ......... 62 
A.3.4. Applications that Send Responses ....o.oooooooooooooooooo.. 62 
A.4. Access Control Model Design Requirements ...............-... 63 
BATEDES” ~AGAESS SSS ne veces it ej 63 
Parl Copyright Statement. tia ers cite ah chaise ay eet oie wets a aye ata 64 


Harrington, et al. Standards Track [Page 3] 


RFC 3411 Architecture for SNMP Management Frameworks December 2002 


1. Introduction 
1.1. Overview 


This document defines a vocabulary for describing SNMP Management 
Frameworks, and an architecture for describing the major portions of 
SNMP Management Frameworks. 


This document does not provide a general introduction to SNMP. Other 
documents and books can provide a much better introduction to SNMP. 
Nor does this document provide a history of SNMP. That also can be 
found in books and other documents. 


Section 1 describes the purpose, goals, and design decisions of this 
architecture. 


Section 2 describes various types of documents which define (elements 
of) SNMP Frameworks, and how they fit into this architecture. It 
also provides a minimal road map to the documents which have 
previously defined SNMP frameworks. 


Section 3 details the vocabulary of this architecture and its pieces. 
This section is important for understanding the remaining sections, 
and for understanding documents which are written to fit within this 
architecture. 


Section 4 describes the primitives used for the abstract service 
interfaces between the various subsystems, models and applications 
within this architecture. 


Section 5 defines a collection of managed objects used to instrument 
SNMP entities within this architecture. 


Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. 


Appendix A contains guidelines for designers of Models which are 
expected to fit within this architecture. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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1.2. SNMP 
An SNMP management system contains: 


- several (potentially many) nodes, each with an SNMP entity 
containing command responder and notification originator 
applications, which have access to management instrumentation 
(traditionally called agents); 


- at least one SNMP entity containing command generator and/or 
notification receiver applications (traditionally called a 
manager) and, 


- a management protocol, used to convey management information 
between the SNMP entities. 


SNMP entities executing command generator and notification receiver 
applications monitor and control managed elements. Managed elements 
are devices such as hosts, routers, terminal servers, etc., which are 
monitored and controlled via access to their management information. 


It is the purpose of this document to define an architecture which 
can evolve to realize effective management in a variety of 
configurations and environments. The architecture has been designed 
to meet the needs of implementations of: 


- minimal SNMP entities with command responder and/or 
notification originator applications (traditionally called SNMP 
agents), 


- SNMP entities with proxy forwarder applications (traditionally 
called SNMP proxy agents), 


- command line driven SNMP entities with command generator and/or 
notification receiver applications (traditionally called SNMP 
command line managers), 


- SNMP entities with command generator and/or notification 
receiver, plus command responder and/or notification originator 
applications (traditionally called SNMP mid-level managers or 
dual-role entities), 


- SNMP entities with command generator and/or notification 
receiver and possibly other types of applications for managing 
a potentially very large number of managed nodes (traditionally 
called (network) management stations). 
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1.3. Goals of this Architecture 
This architecture was driven by the following goals: 


- Use existing materials as much as possible. It is heavily 
based on previous work, informally known as SNMPv2u and 
SNMPv2*, based in turn on SNMPv2p. 


- Address the need for secure SET support, which is considered 
the most important deficiency in SNMPv1 and SNMPv2c. 


- Make it possible to move portions of the architecture forward 
in the standards track, even if consensus has not been reached 
on all pieces. 


- Define an architecture that allows for longevity of the SNMP 
Frameworks that have been and will be defined. 


- Keep SNMP as simple as possible. 


- Make it relatively inexpensive to deploy a minimal conforming 
implementation. 


- Make it possible to upgrade portions of SNMP as new approaches 
become available, without disrupting an entire SNMP framework. 


- Make it possible to support features required in large 
networks, but make the expense of supporting a feature directly 
related to the support of the feature. 


1.4. Security Requirements of this Architecture 


Several of the classical threats to network protocols are applicable 
to the management problem and therefore would be applicable to any 
Security Model used in an SNMP Management Framework. Other threats 
are not applicable to the management problem. This section discusses 
principal threats, secondary threats, and threats which are of lesser 
importance. 


The principal threats against which any Security Model used within 
this architecture SHOULD provide protection are: 


Modification of Information 
The modification threat is the danger that some unauthorized 
entity may alter in-transit SNMP messages generated on behalf 
of an authorized principal in such a way as to effect 
unauthorized management operations, including falsifying the 
value of an object. 
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Masquerade 
The masquerade threat is the danger that management operations 
not authorized for some principal may be attempted by assuming 
the identity of another principal that has the appropriate 
authorizations. 


Secondary threats against which any Security Model used within this 
architecture SHOULD provide protection are: 


Message Stream Modification 
The SNMP protocol is typically based upon a connectionless 
transport service which may operate over any subnetwork 


service. The re-ordering, delay or replay of messages can and 
does occur through the natural operation of many such 
subnetwork services. The message stream modification threat is 


the danger that messages may be maliciously re-ordered, delayed 
or replayed to an extent which is greater than can occur 
through the natural operation of a subnetwork service, in order 
to effect unauthorized management operations. 


Disclosure 
The disclosure threat is the danger of eavesdropping on the 
exchanges between SNMP engines. Protecting against this threat 


may be required as a matter of local policy. 


There are at least two threats against which a Security Model within 
this architecture need not protect, since they are deemed to be of 
lesser importance in this context: 


Denial of Service 
A Security Model need not attempt to address the broad range of 
attacks by which service on behalf of authorized users is 
denied. Indeed, such denial-of-service attacks are in many 
cases indistinguishable from the type of network failures with 
which any viable management protocol must cope as a matter of 
course. 


Traffic Analysis 
A Security Model need not attempt to address traffic analysis 
attacks. Many traffic patterns are predictable - entities may 
be managed on a regular basis by a relatively small number of 
management stations - and therefore there is no significant 
advantage afforded by protecting against traffic analysis. 
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1.5. Design Decisions 


Various design decisions were made in support of the goals of the 
architecture and the security requirements: 


- Architecture 
An architecture should be defined which identifies the 
conceptual boundaries between the documents. Subsystems should 


be defined which describe the abstract services provided by 
specific portions of an SNMP framework. Abstract service 
interfaces, as described by service primitives, define the 
abstract boundaries between documents, and the abstract 
services that are provided by the conceptual subsystems of an 
SNMP framework. 


- Self-contained Documents 
Elements of procedure plus the MIB objects which are needed for 
processing for a specific portion of an SNMP framework should 
be defined in the same document, and as much as possible, 
should not be referenced in other documents. This allows 
pieces to be designed and documented as independent and self- 
contained parts, which is consistent with the general SNMP MIB 
module approach. As portions of SNMP change over time, the 
documents describing other portions of SNMP are not directly 
impacted. This modularity allows, for example, Security 
Models, authentication and privacy mechanisms, and message 
formats to be upgraded and supplemented as the need arises. 
The self-contained documents can move along the standards track 
on different time-lines. 


This modularity of specification is not meant to be interpreted 
as imposing any specific requirements on implementation. 


- Threats 
The Security Models in the Security Subsystem SHOULD protect 
against the principal and secondary threats: modification of 
information, masquerade, message stream modification and 
disclosure. They do not need to protect against denial of 
service and traffic analysis. 


- Remote Configuration 
The Security and Access Control Subsystems add a whole new set 
of SNMP configuration parameters. The Security Subsystem also 
requires frequent changes of secrets at the various SNMP 
entities. To make this deployable in a large operational 
environment, these SNMP parameters must be remotely 
configurable. 
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- Controlled Complexity 
It is recognized that producers of simple managed devices want 
to keep the resources used by SNMP to a minimum. At the same 
time, there is a need for more complex configurations which can 
spend more resources for SNMP and thus provide more 
functionality. The design tries to keep the competing 
requirements of these two environments in balance and allows 
the more complex environments to logically extend the simple 
environment. 
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2. Documentation Overview 


The following figure shows the set of documents that fit within the 
SNMP Architecture. 


Tene og ee a ee ek Se TE Document. Set += AS ee SA i 
| +---------- + +----------------- + +---------------- + | 
| Document Applicability Coexistence 
Roadmap Statement & Transition 
| +---------- + +----------------—- + +---------------- + | 
| 
| AZ 5555-5 + | 
| Message Handling | | 
| | +---------------- + +----------------- + +----------------- + | | 
Transport Message Security | 
| | Mappings Processing and 
| | | | Dispatcher | | | 
| | +---------------- + +----------------- + A + | | 
| +--------------------------------------------------------------- + | 
| | 
hee oe ee ie ee ee ee eee Se ear oe + 
| | PDU Handling | 
| | +---------------- + +----------------- + +----------------- + | 
| | | Protocol | Applications | Access | | 
| | | Operations | | Control | | 
| | +---------------- + +----------------- + +----------------- + | | 
| e + | 
| +--------------------------------------------------------------- + | 
| | Information Model | | 
| | +-------------- +  +-------------- + Ho + | | 
| | Structure of | | Textual | | Conformance | | 
Management Conventions Statements 
| Information | | 
| +-------------- +  +-------------- + +--------------- + | | 
| O 55 5-5-5 + | 
| | 
| +--------------------------------------------------------------- + | 
| MIB Modules written in various formats, e.g 
+---------------- + HZ + 
| | | SMIv1 (STD 18) | | SMIv2 (STD 58) | | | 
| | | format | | format | | 
| | +---------------- + +---------------- + et 
| +--------------------------------------------------------------- + | 
| | 
ho O eS A ee ee + 
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Each of these documents may be replaced or supplemented. This 
Architecture document specifically describes how new documents fit 
into the set of documents in the area of Message and PDU handling. 


2.1. Document Roadmap 


One or more documents may be written to describe how sets of 
documents taken together form specific Frameworks. The configuration 
of document sets might change over time, so the "road map" should be 
maintained in a document separate from the standards documents 
themselves. 


An example of such a roadmap is "Introduction and Applicability 
Statements for the Internet-Standard Management Framework" [RFC3410]. 


2.2. Applicability Statement 


SNMP is used in networks that vary widely in size and complexity, by 
organizations that vary widely in their requirements of management. 
Some models will be designed to address specific problems of 
management, such as message security. 


One or more documents may be written to describe the environments to 
which certain versions of SNMP or models within SNMP would be 
appropriately applied, and those to which a given model might be 
inappropriately applied. 


2.3. Coexistence and Transition 


The purpose of an evolutionary architecture is to permit new models 
to replace or supplement existing models. The interactions between 
models could result in incompatibilities, security "holes", and other 
undesirable effects. 


The purpose of Coexistence documents is to detail recognized 
anomalies and to describe required and recommended behaviors for 
resolving the interactions between models within the architecture. 


Coexistence documents may be prepared separately from model 
definition documents, to describe and resolve interaction anomalies 
between a model definition and one or more other model definitions. 


Additionally, recommendations for transitions between models may also 
be described, either in a coexistence document or in a separate 
document. 


Harrington, et al. Standards Track [Page 11] 


RFC 3411 Architecture for SNMP Management Frameworks December 2002 


2: 


2 


2: 


One such coexistence document is [RFC2576], "Coexistence between 
Version 1, Version 2, and Version 3 of the Internet-Standard Network 
Management Framework". 


4. Transport Mappings 


SNMP messages are sent over various transports. It is the purpose of 
Transport Mapping documents to define how the mapping between SNMP 
and the transport is done. 


5. Message Processing 


A Message Processing Model document defines a message format, which 
is typically identified by a version field in an SNMP message header. 
The document may also define a MIB module for use in message 
processing and for instrumentation of version-specific interactions. 


An SNMP engine includes one or more Message Processing Models, and 
thus may support sending and receiving multiple versions of SNMP 
messages. 


6. Security 


Some environments require secure protocol interactions. Security is 
normally applied at two different stages: 


- in the transmission/receipt of messages, and 
- in the processing of the contents of messages. 


For purposes of this document, "security" refers to message-level 
security; "access control" refers to the security applied to protocol 
operations. 


Authentication, encryption, and timeliness checking are common 
functions of message level security. 


A security document describes a Security Model, the threats against 
which the model protects, the goals of the Security Model, the 
protocols which it uses to meet those goals, and it may define a MIB 
module to describe the data used during processing, and to allow the 
remote configuration of message-level security parameters, such as 
keys. 


An SNMP engine may support multiple Security Models concurrently. 
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2.7. Access Control 


During processing, it may be required to control access to managed 
objects for operations. 


An Access Control Model defines mechanisms to determine whether 
access to a managed object should be allowed. An Access Control 


Model 


may define a MIB module used during processing and to allow the 


remote configuration of access control policies. 


2.8. Protocol Operations 
SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP 
PDUs define the operations performed by the receiving SNMP engine. 
It is the purpose of a Protocol Operations document to define the 
operations of the protocol with respect to the processing of the 
PDUs. Every PDU belongs to one or more of the PDU classes defined 
below: 
1) Read Class: 
The Read Class contains protocol operations that retrieve 
management information. For example, [RFC3416] defines the 
following protocol operations for the Read Class: GetRequest- 
PDU, GetNextRequest-PDU, and GetBulkRequest-PDU. 
2) Write Class: 
The Write Class contains protocol operations which attempt to 
modify management information. For example, [RFC3416] defines 
the following protocol operation for the Write Class: 
SetRequest-PDU. 
3) Response Class: 
The Response Class contains protocol operations which are sent 
in response to a previous request. For example, [RFC3416] 
defines the following for the Response Class: Response-PDU, 
Report-PDU. 
4) Notification Class: 


The Notification Class contains protocol operations which send 
a notification to a notification receiver application. For 
example, [RFC3416] defines the following operations for the 
Notification Class: Trapv2-PDU, InformRequest-PDU. 
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5) Internal Class: 


The Internal Class contains protocol operations which are 
exchanged internally between SNMP engines. For example, 
[RFC3416] defines the following operation for the Internal 
Class: Report-PDU. 


The preceding five classifications are based on the functional 
properties of a PDU. It is also useful to classify PDUs based on 
whether a response is expected: 


6) Confirmed Class: 


The Confirmed Class contains all protocol operations which 
cause the receiving SNMP engine to send back a response. For 
example, [RFC3416] defines the following operations for the 
Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, 
GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU. 


7) Unconfirmed Class: 


The Unconfirmed Class contains all protocol operations which 
are not acknowledged. For example, [RFC3416] defines the 
following operations for the Unconfirmed Class: Report-PDU, 
Trapv2-PDU, and GetResponse-PDU. 


An application document defines which Protocol Operations are 
supported by the application. 


2.9. Applications 


An SNMP entity normally includes a number of applications. 
Applications use the services of an SNMP engine to accomplish 
specific tasks. They coordinate the processing of management 
information operations, and may use SNMP messages to communicate with 
other SNMP entities. 


An applications document describes the purpose of an application, the 
services required of the associated SNMP engine, and the protocol 
operations and informational model that the application uses to 
perform management operations. 


An application document defines which set of documents are used to 
specifically define the structure of management information, textual 
conventions, conformance requirements, and operations supported by 
the application. 
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2.10. Structure of Management Information 


Management information is viewed as a collection of managed objects, 
residing in a virtual information store, termed the Management 
Information Base (MIB). Collections of related objects are defined 
in MIB modules. 


It is the purpose of a Structure of Management Information document 
to establish the notation for defining objects, modules, and other 
elements of managed information. 


2.11. Textual Conventions 


When designing a MIB module, it is often useful to define new types 
similar to those defined in the SMI, but with more precise semantics, 
or which have special semantics associated with them. These newly 
defined types are termed textual conventions, and may be defined in 
separate documents, or within a MIB module. 


2.12. Conformance Statements 


It may be useful to define the acceptable lower-bounds of 
implementation, along with the actual level of implementation 
achieved. It is the purpose of the Conformance Statements document 
to define the notation used for these purposes. 


2.13. Management Information Base Modules 


MIB documents describe collections of managed objects which 
instrument some aspect of a managed node. 


2.13.1. SNMP Instrumentation MIBs 


An SNMP MIB document may define a collection of managed objects which 
instrument the SNMP protocol itself. In addition, MIB modules may be 
defined within the documents which describe portions of the SNMP 
architecture, such as the documents for Message processing Models, 
Security Models, etc. for the purpose of instrumenting those Models, 
and for the purpose of allowing their remote configuration. 


2.14. SNMP Framework Documents 


This architecture is designed to allow an orderly evolution of 
portions of SNMP Frameworks. 


Throughout the rest of this document, the term "subsystem" refers to 


an abstract and incomplete specification of a portion of a Framework, 
that is further refined by a model specification. 
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A "model" describes a specific design of a subsystem, defining 
additional constraints and rules for conformance to the model. A 
model is sufficiently detailed to make it possible to implement the 
specification. 


An "implementation" is an instantiation of a subsystem, conforming to 
one or more specific models. 


SNMP version 1 (SNMPv1), is the original Internet-Standard Network 
Management Framework, as described in RFCs 1155, 1157, and 1212. 


SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 
SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580, 
and STD 62, RFCs 3416, 3417, and 3418. SNMPv2 has no message 
definition. 

The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 
Framework which supplements the SNMPv2 Framework, as described in 
[RFC1901]. It adds the SNMPv2c message format, which is similar to 
the SNMPvl message format. 


SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 
supplements the SNMPv2 Framework, by supporting the following: 


- a new SNMP message format, 

- Security for Messages, 

- Access Control, and 

- Remote configuration of SNMP parameters. 
Other SNMP Frameworks, i.e., other configurations of implemented 
subsystems, are expected to also be consistent with this 
architecture. 


3. Elements of the Architecture 


This section describes the various elements of the architecture and 
how they are named. There are three kinds of naming: 


1) the naming of entities, 
2) the naming of identities, and 


3) the naming of management information. 
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This architecture also defines some names for other constructs that 
are used in the documentation. 

3.1. The Naming of Entities 
An SNMP entity is an implementation of this architecture. Each such 
SNMP entity consists of an SNMP engine and one or more associated 


applications. 


The following figure shows details about an SNMP entity and the 
components within it. 


SNMP engine (identified by snmpEngineID) 


| | 
| | 
| +------------ + +------------ + +----------- + +----------- + | 
| | | | | | | | | | 
| | Dispatcher | | Message | | Security | | Access | | 
Processing Subsystem Control 
Subsystem Subsystem 
| | | | ae 
|  +------------ + +------------ + +----------- + +----------- + | 
| | 
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| 
| 
|  +------------- + +-------------- + +-------------- + | 
| | Command | | Notification | | Proxy | 
| Generator | | Receiver | | Forwarder 
+------------- + +-------------- + +-------------- + 
| | 
| +------------- + +-------------- + +-------------- + | 
| | Command | | Notification | | Other | 
| | Responder | | Originator | | 
+------------- + +-------------- + +-------------- + 
+------------------------------------------------------------- + 
HO + 
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3.1.1. SNMP engine 


An SNMP engine provides services for sending and receiving messages, 
authenticating and encrypting messages, and controlling access to 
managed objects. There is a one-to-one association between an SNMP 
engine and the SNMP entity which contains it. 


The engine contains: 

1) a Dispatcher, 

2) a Message Processing Subsystem, 

3) a Security Subsystem, and 

4) an Access Control Subsystem. 

3.1.1.1. snmpEngineID 

Within an administrative domain, an snmpEngineID is the unique and 
unambiguous identifier of an SNMP engine. Since there is a one-to- 
one association between SNMP engines and SNMP entities, it also 
uniquely and unambiguously identifies the SNMP entity within that 
administrative domain. Note that it is possible for SNMP entities in 
different administrative domains to have the same value for 
snmpEngineID. Federation of administrative domains may necessitate 


assignment of new values. 


3.1.1.2. Dispatcher 


There is only one Dispatcher in an SNMP engine. It allows for 
concurrent support of multiple versions of SNMP messages in the SNMP 
engine. It does so by: 


- sending and receiving SNMP messages to/from the network, 


- determining the version of an SNMP message and interacting with 
the corresponding Message Processing Model, 


- providing an abstract interface to SNMP applications for 
delivery of a PDU to an application. 


- providing an abstract interface for SNMP applications that 
allows them to send a PDU to a remote SNMP entity. 
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3.1.1.3. Message Processing Subsystem 


The Message Processing Subsystem is responsible for preparing 
messages for sending, and extracting data from received messages. 


The Message Processing Subsystem potentially contains multiple 
Message Processing Models as shown in the next figure. 


* One or more Message Processing Models may be present. 


| | 
| | 
| | 
| +------------ + +------------ + +------------ + +------------ + | 
* * * * 
| SNMPv3 SNMPv1 SNMPv2c Other 
| | Message | | Message | | Message | | Message | | 
| | Processing | | Processing | | Processing | | Processing | | 
| | Model | | Model | | Model | | Model | 
al ml Hl. 2 i al | | 
$ A SaaS =a ai A Gee ee + 
A O O O O Aa + 


3.1.1.3.1. Message Processing Model 
Each Message Processing Model defines the format of a particular 


version of an SNMP message and coordinates the preparation and 
extraction of each such version-specific message format. 
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3.1.1.4. Security Subsystem 
The Security Subsystem provides security services such as the 
authentication and privacy of messages and potentially contains 


multiple Security Models as shown in the following figure 


* One or more Security Models may be present. 


| | 
| | 
| | 
| +---------------- q, ee ee ee $+ $------------------- + | 
| | a lo ar ae 
| | User-Based | | Other | | Other | 
Security Security Security 
Model Model Model 
d | | | | | 
|  +---------------- +  $o---------------- O + | 
| | 
$ -- - --- = = + 


3.1.1.4.1. Security Model 
A Security Model specifies the threats against which it protects, the 
goals of its services, and the security protocols used to provide 


security services such as authentication and privacy. 


3.1.1.4.2. Security Protocol 
A Security Protocol specifies the mechanisms, procedures, and MIB 


objects used to provide a security service such as authentication or 
privacy. 
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3.1.2. Access Control Subsystem 


The Access Control Subsystem provides authorization services by means 
of one or more (*) Access Control Models. 


| | 

| | 

| AO O + +----------------- + AO O + | 

| | a | a) UA an | 

| | View-Based | | Other | | Other | 

| | Access | | Access | | Access | 

| | Control | | Control | | Control | 

| | Model | | Model | | Model | 

PA | | | | yl 
AO + +----------------- + AO + 

| | 

$ O E O O O O A S + 


3.1.2.1. Access Control Model 


An Access Control Model defines a particular access decision function 
in order to support decisions regarding access rights. 


3.1.3. Applications 
There are several types of applications, including: 


- command generators, which monitor and manipulate management 
data, 


- command responders, which provide access to management data, 

- notification originators, which initiate asynchronous messages, 
- notification receivers, which process asynchronous messages, 
and 

- proxy forwarders, which forward messages between entities. 


These applications make use of the services provided by the SNMP 
engine. 
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3.1.3.1. SNMP Manager 
An SNMP entity containing one or more command generator and/or 
notification receiver applications (along with their associated SNMP 


engine) has traditionally been called an SNMP manager. 


(traditional SNMP manager) 


$ nn E E ANE + 
pressent a o aida ty eee asssa=sea= + SNMP entity 
| NOTIFICATION | | NOTIFICATION | | COMMAND | 
| | ORIGINATOR | | RECEIVER | | GENERATOR 
| | applications | | applications | | applications | 
| +-------------- + +-------------- + +-------------- + | 
| : is A | 
| | | | 
v v v 
| Ho +-------- AO + | 
| A | 
| | +--------------------- + +---------------- + | 
| | | Message Processing | | Security | 
| Dispatcher v | Subsystem | | Subsystem | 
+------------------- + +------------ + | 
| | PDU Dispatcher | | +->| v1MP x | <---> SS Sess s-SS + | 
| | | | | +--------- + | | | other ||| 
|| E — + | | | security | | | 
| | | | +->| v2cMP * |<--->| | Model | | 
| | Message | | | +------------ + | | +------------ + | 
Dispatcher <--==---== >+ 
ie. | | | 
is | | | +->| v3mp * |<--->| | User-based | | | 
| | Transport | | |  +------------ + | | | Security UN 
| | Mapping eee + | | | model || 
| | (e.g., RFC 3417) | | +->| othermp * |<--->| +------------ + | 
eee aoe El +2- + 1 | | 
2 $ po A + 
| | | 
| v | 
pee ae ee A ae aS a pe ee eA oe Seer n a a + 
+= + += + Ho + 
| upp | | 1PX | | other | 
+= + += + +------- + 
| | | * One or more models may be present. 
v v v 
A + 
| Network | 
A = + 
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3.1.3.2. SNMP Agent 
An SNMP entity containing one or more command responder and/or 


notification originator applications (along with their associated 
SNMP engine) has traditionally been called an SNMP agent. 
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* One or more models may be present. 


+------------------------------ + 
| Network | 
+------------------------------ + 

| | | 

v v v 
+----- + +----- + +------- + 
| upp | | IPx | | other | 
===> + +----- + +------- + (traditional SNMP agent) 
$------------- = $$ 5 5 5 == + 
| : | 
| | +--------------------—- + +---------------- + | 
| | | Message Processing | | Security | 
| Dispatcher v | Subsystem | Subsystem | 

+------------------- + +------------ + 

| | Transport | | +->| v1MP |<--->| Paes SS == ES + | 
| | mapping | | | +=- + | | | other ||| 
| | (e.g., RFC 3417) | | | +------------ + | | | Security | | 
| | | | +->| v2cMP * |<--->| | Model | | 

Message | | ESSE SST SS SS + HS TSE SES + | 
| Dispatcher <--------- > PREIS + ASS + 
| | | | +->| v3MP * |<--->| | User-based | | | 
|| | | | teen + | | | security | | | 
| | PDU Dispatcher | | | +------------ a | | Model | | 
| +------------------- + | +->| othermp * |<--->| +------------ + | | 
| : [o + || | 

| Ho + +---------------- + 
| v | 
| +------—- a + | 
| 2 : : | 
| | | | 
v v v 

| +------------- +  +--------- +  +-------------- + +------------- + | 
| COMMAND | | access | | NOTIFICATION | | PROXY | | 
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | FORWARDER | | 
| | application | | | | applications | application | | 
| +------------- +  +--------—- +  +-------------- + +------------- + | 
Io | | 
| v v | 
| +---------------------------------------------- + | 
| | MIB instrumentation SNMP entity | 
$------- $5 + 
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3.2. The Naming of Identities 


principal 
| 
| 
$---------------------------- | ------------- + 
| SNMP engine v 
| $-------------- + | 
| | 
| +----------------- | securityName |---+ | 
| | Security Model | | | | 
| | t-----------—-- + | | 
| | a ol 
| | | | 
v 
An pl 
| | | i ih 
| | | Model Hi i 
| | | Dependent | | | 
| | | Security ID i ul 
| | 
le ee | 
| | e | | 
| | | || 
o |---------- + | 
| | | 
| | 
E a = | === + 
| 
v 
network 


3.2.01. Principal 


A principal is the "who" on whose behalf services are provided or 
processing takes place. 


A principal can be, among other things, an individual acting ina 
particular role; a set of individuals, with each acting ina 
particular role; an application or a set of applications; and 
combinations thereof. 


3.2.2. securityName 
A securityName is a human readable string representing a principal. 


It has a model-independent format, and can be used outside a 
particular Security Model. 
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3.2.3. Model-dependent security ID 


A model-dependent security ID is the model-specific representation of 
a securityName within a particular Security Model. 


Model-dependent security IDs may or may not be human readable, and 


have a model-dependent syntax. Examples include community names, and 
user names. 


The transformation of model-dependent security IDs into securityNames 
and vice versa is the responsibility of the relevant Security Model. 


3.3. The Naming of Management Information 
Management information resides at an SNMP entity where a Command 
Responder Application has local access to potentially multiple 


contexts. This application uses a contextEngineID equal to the 
snmpEngineID of its associated SNMP engine. 
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SNMP entity (identified by snmpEnginelD, for example: 
"800002b804616263’H (enterpise 696, string "abc") 


SNMP engine (identified by snmpEnginelD) 


| | 
| | 
| +------------- + +------------ + +----------- + +----------- + | 
| Dispatcher Message Security Access | 

Processing | | Subsystem | | Control | | 

Subsystem | | | | Subsystem | | 
| | | 
| +------------- + $------------ + $----------- + $----------- + | 
| | 
Hipatia eas ee eee ee eee ee ae eS eae Seo + 
Fm O O O O O O O R E + 


Command Responder Application 
(contextEngineID, example: ’800002b804616263’H) 


| | 
| | 
| | 
| example contextNames: | 
| | 
| | 
| | 


"bridgel" "bridge2" "" (default) 
| | | 
+-----—- | ------------------ | ------------------- | -------------- + 
q AAA J m : 
| MIB | instrumentation | | | 
| +---v------------ + +---v-----------—- E + | 
| | context | | context | | context | 
| | li Dea | | 
$ + $ + $ + 
| | bridge MIB | | bridge MIB | | some MIB | 
kt | Sees All eres O sore ete E] 
| | WAN | 
| | | #------------ + | | 
| | | other MIB | | | 
| | || LI 
a a ii ii + 
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3.3.1. An SNMP Context 


An SNMP context, or just "context" for short, is a collection of 
management information accessible by an SNMP entity. An item of 
management information may exist in more than one context. An SNMP 
entity potentially has access to many contexts. 


Typically, there are many instances of each managed object type 
within a management domain. For simplicity, the method for 
identifying instances specified by the MIB module does not allow each 
instance to be distinguished amongst the set of all instances within 
a management domain; rather, it allows each instance to be identified 
only within some scope or "context", where there are multiple such 
contexts within the management domain. Often, a context is a 
physical device, or perhaps, a logical device, although a context can 
also encompass multiple devices, or a subset of a single device, or 
even a subset of multiple devices, but a context is always defined as 
a subset of a single SNMP entity. Thus, in order to identify an 
individual item of management information within the management 
domain, its contextName and contextEngineID must be identified in 
addition to its object type and its instance. 


For example, the managed object type ifDescr [RFC2863], is defined as 
the description of a network interface. To identify the description 
of device-X’s first network interface, four pieces of information are 
needed: the snmpEngineID of the SNMP entity which provides access to 
the management information at device-X, the contextName (device-X), 
the managed object type (ifDescr), and the instance ("1"). 


Each context has (at least) one unique identification within the 
management domain. The same item of management information can exist 
in multiple contexts. An item of management information may have 
multiple unique identifications. This occurs when an item of 
management information exists in multiple contexts, and this also 
occurs when a context has multiple unique identifications. 


The combination of a contextEngineID and a contextName unambiguously 
identifies a context within an administrative domain; note that there 
may be multiple unique combinations of contextEngineID and 
contextName that unambiguously identify the same context. 


3.3.2. contextEngineID 
Within an administrative domain, a contextEngineID uniquely 


identifies an SNMP entity that may realize an instance of a context 
with a particular contextName. 
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3.3.3. contextName 


A contextName is used to name a context. Each contextName MUST be 
unique within an SNMP entity. 


3.3.4.  scopedPDU 


A scopedPDU is a block of data containing a contextEnginelD, a 
contextName, and a PDU. 


The PDU is an SNMP Protocol Data Unit containing information named in 
the context which is unambiguously identified within an 
administrative domain by the combination of the contextEngineID and 
the contextName. See, for example, RFC 3416 for more information 
about SNMP PDUs. 

3.4. Other Constructs 

3.4.1. maxSizeResponseScopedPDU 
The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that 
a PDU’s sender would be willing to accept. Note that the size of a 
scopedPDU does not include the size of the SNMP message header. 


3.4.2. Local Configuration Datastore 


The subsystems, models, and applications within an SNMP entity may 
need to retain their own sets of configuration information. 


Portions of the configuration information may be accessible as 
managed objects. 


The collection of these sets of information is referred to as an 
entity's Local Configuration Datastore (LCD). 


3.4.3. securityLevel 
This architecture recognizes three levels of security: 
- without authentication and without privacy (noAuthNoPriv) 
- with authentication but without privacy (authNoPriv) 


- with authentication and with privacy (authPriv) 
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These three values are ordered such that noAuthNoPriv is less than 
authNoPriv and authNoPriv is less than authPriv. 


Every message has an associated securityLevel. All Subsystems 
(Message Processing, Security, Access Control) and applications are 
REQUIRED to either supply a value of securityLevel or to abide by the 
supplied value of securityLevel while processing the message and its 
contents. 


4. Abstract Service Interfaces 


Abstract service interfaces have been defined to describe the 
conceptual interfaces between the various subsystems within an SNMP 
entity. The abstract service interfaces are intended to help clarify 
the externally observable behavior of SNMP entities, and are not 
intended to constrain the structure or organization of 
implementations in any way. Most specifically, they should not be 
interpreted as APIs or as requirements statements for APIs. 


These abstract service interfaces are defined by a set of primitives 
that define the services provided and the abstract data elements that 
are to be passed when the services are invoked. This section lists 
the primitives that have been defined for the various subsystems. 


4.1. Dispatcher Primitives 
The Dispatcher typically provides services to the SNMP applications 


via its PDU Dispatcher. This section describes the primitives 
provided by the PDU Dispatcher. 
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4.1.1. Generate Outgoing Request or Notification 


The PDU Dispatcher provides the following primitive for an 
application to send an SNMP Request or Notification to another SNMP 


entity: 
statusInformation = -- sendPduHandle if success 
-=- errorIndication if failure 
sendPdu ( 
IN transportDomain -- transport domain to be used 
IN transportAddress -- transport address to be used 
IN messageProcessingModel —- typically, SNMP version 
IN securityModel -- Security Model to use 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security requested 
IN contextEnginelD -- data from/at this entity 
IN contextName -- data from/in this context 
IN pduVersion -- the version of the PDU 
IN PDU -- SNMP Protocol Data Unit 
IN expectResponse -- TRUE or FALSE 
) 
4.1.2. Process Incoming Request or Notification PDU 


The PDU Dispatcher provides the following primitive to pass an 
incoming SNMP PDU to an application: 


processPdu ( -- process Request/Notification PDU 
IN messageProcessingModel —- typically, SNMP version 
IN securityModel -- Security Model in use 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security 
IN contextEnginelD -- data from/at this SNMP entity 
IN contextName -- data from/in this context 
IN pduVersion -- the version of the PDU 
IN PDU -- SNMP Protocol Data Unit 
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 
IN stateReference -- reference to state information 


) -- needed when sending a response 
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4.1.3. Generate Outgoing Response 


The PDU Dispatcher provides the following primitive for an 
application to return an SNMP Response PDU to the PDU Dispatcher: 


result = -- SUCCESS or FAILURE 
returnResponsePdu ( 
IN messageProcessingModel —- typically, SNMP version 
IN securityModel -- Security Model in use 
IN securityName -- on behalf of this principal 
IN securityLevel -- same as on incoming request 
IN contextEnginelD -- data from/at this SNMP entity 
IN contextName -- data from/in this context 
IN pduVersion -- the version of the PDU 
IN PDU —- SNMP Protocol Data Unit 
IN maxSizeResponseScopedPDU -- maximum size sender can accept 
IN stateReference -- reference to state information 
-- as presented with the request 
IN statusInformation —- success or errorIndication 


) -- error counter OID/value if error 
4.1.4. Process Incoming Response PDU 


The PDU Dispatcher provides the following primitive to pass an 
incoming SNMP Response PDU to an application: 


processResponsePdu ( -=- process Response PDU 
IN messageProcessingModel —- typically, SNMP version 
IN securityModel -- Security Model in use 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security 
IN contextEnginelD -- data from/at this SNMP entity 
IN contextName -- data from/in this context 
IN pduVersion -- the version of the PDU 
IN PDU -- SNMP Protocol Data Unit 
IN statusInformation -- success or errorIndication 
IN sendPduHandle -- handle from sendPdu 


) 
4.1.5. Registering Responsibility for Handling SNMP PDUs 


Applications can register/unregister responsibility for a specific 
contextEngineID, for specific pduTypes, with the PDU Dispatcher 
according to the following primitives. The list of particular 
pduTypes that an application can register for is determined by the 
Message Processing Model(s) supported by the SNMP entity that 
contains the PDU Dispatcher. 
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statusInformation = 
registerContextEnginelD ( 
IN contextEngineID 
IN pduType 
) 


unregisterContextEnginelD ( 
IN contextEngineID 
IN pduType 
) 


success or errorIndication 


take responsibility for this one 
the pduType(s) to be registered 


give up responsibility for this one 
the pduType(s) to be unregistered 


Note that realizations of the registerContextEngineID and 
unregisterContextEngineID abstract service interfaces may provide 
implementation-specific ways for applications to register/deregister 
responsibility for all possible values of the contextEngineID or 


pduType parameters. 


4.2. Message Processing Subsystem Primitives 


The Dispatcher interacts with a Message Processing Model to process a 
specific version of an SNMP Message. This section describes the 
primitives provided by the Message Processing Subsystem. 


4.2.1. Prepare Outgoing SNMP Request or Notification Message 


The Message Processing Subsystem provides this service primitive for 
preparing an outgoing SNMP Request or Notification Message: 


statusInformation = 
prepareOutgoingMessage ( 


OUT destTransportDomain 


OUT destTransportAddress 


OUT outgoingMessage 


OUT outgoingMessageLength 


) 


IN transportDomain 
IN transportAddress 
IN messageProcessingModel 
IN securityModel 

IN securityName 

IN securityLevel 

IN contextEngineID 
IN contextName 

IN pduVersion 

IN PDU 

IN expectResponse 
IN sendPduHandle 


- success or errorIndication 


- transport domain to be used 
- transport address to be used 
- typically, SNMP version 

- Security Model to use 

- on behalf of this principal 
- Level of Security requested 
- data from/at this entity 

- data from/in this context 

- the version of the PDU 

- SNMP Protocol Data Unit 

— TRUE or FALSE 

- the handle for matching 

- incoming responses 

- destination transport domain 
- destination transport address 
- the message to send 

- its length 
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Prepare an Outgoing SNMP Response Message 


The Message Processing Subsystem provides this service primitive for 
preparing an outgoing SNMP Response Message: 


result 


prepareResponseMessage ( 


H 


HHHHHHHHH 
ZZBZBZZZZZZZ 
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messageProcessingModel 
securityModel 
securityName 
securityLevel 
contextEngineID 
contextName 

pduVersion 

PDU 
maxSizeResponseScopedPDU 
stateReference 


statusInformation 


destTransportDomain 
destTransportAddress 
outgoingMessage 
outgoingMessageLength 
) 


Standards Track 


SUCCESS or FAILURE 


typically, SNMP version 

same as on incoming request 
same as on incoming request 
same as on incoming request 
data from/at this SNMP entity 
data from/in this context 

the version of the PDU 

SNMP Protocol Data Unit 
maximum size able to accept 
reference to state information 
as presented with the request 
success or errorIndication 
error counter OID/value if error 
destination transport domain 
destination transport address 
the message to send 

its length 
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4.2.3. Prepare Data Elements from an Incoming SNMP Message 


The Message Processing Subsystem provides this service primitive for 
preparing the abstract data elements from an incoming SNMP message: 


result 


prepareDataElements ( 
transportDomain 
transportAddress 


H 
22424 


oOo0oo0o0O000O0OHHH 
Ç 
JHHHHA 


wholeMsg 
wholeMsgLength 


messageProcessingModel 


securityModel 
securityName 
securityLevel 


contextEngineID 


contextName 
pduVersion 
PDU 

pduType 
sendPduHandle 


maxSizeResponseScopedPDU 
statusInformation 


stateReference 


) 


SUCCESS or errorIndication 


origin transport domain 
origin transport address 

as received from the network 
as received from the network 
typically, SNMP version 
Security Model to use 

on behalf of this principal 
Level of Security requested 
data from/at this entity 
data from/in this context 
the version of the PDU 

SNMP Protocol Data Unit 

SNMP PDU type 

handle for matched request 


maximum size sender can accept 


success or errorIndication 

error counter OID/value if error 
reference to state information 
to be used for possible Response 


4.3. Access Control Subsystem Primitives 


Applications are the typical clients of the service(s) of the Access 
Control Subsystem. 


The following primitive is provided by the Access Control Subsystem 


to check if access is allowed: 


statusInformation = 


isAccessAllowed ( 
IN securityModel 
IN securityName 
IN securityLevel 
IN viewType 

IN contextName 
IN variableName 


) 
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success or errorIndication 


Security Model in use 


principal who wants to access 
Level of Security 


read, write, or notify view 
context containing variableName 


OID for the managed object 
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4.4. Security Subsystem Primitives 


The Message Processing Subsystem is the typical client of the 
services of the Security Subsystem. 


4.4.1. Generate a Request or Notification Message 


The Security Subsystem provides the following primitive to generate a 
Request or Notification message: 


statusInformation = 
generateRequestMsg ( 


IN messageProcessingModel -—- typically, SNMP version 
IN globalData -- message header, admin data 
IN maxMessageSize -—- of the sending SNMP entity 
IN securityModel -—- for the outgoing message 
IN securityEnginelD -- authoritative SNMP entity 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security requested 
IN scopedPDU -- message (plaintext) payload 
OUT securityParameters -- filled in by Security Module 
OUT wholeMsg -- complete generated message 
OUT wholeMsgLength -- length of the generated message 
) 
4.4.2. Process Incoming Message 


The Security Subsystem provides the following primitive to process an 
incoming message: 


statusInformation = -- errorIndication or success 
-- error counter OID/value if error 
processIncomingMsg ( 


IN messageProcessingModel -=- typically, SNMP version 

IN maxMessageSize -—- of the sending SNMP entity 

IN securityParameters -- for the received message 

IN securityModel -- for the received message 

IN securityLevel -- Level of Security 

IN wholeMsg -- as received on the wire 

IN wholeMsgLength -- length as received on the wire 
OUT securityEngineID -- authoritative SNMP entity 

OUT securityName -- identification of the principal 
OUT scopedPDU, -- message (plaintext) payload 
OUT maxSizeResponseScopedPDU -- maximum size sender can handle 
OUT securityStateReference -- reference to security state 


) —- information, needed for response 
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4.4.3. Generate a Response Message 


The Security Subsystem provides the 


Response message: 


statusInformation = 
generateResponseMsg ( 
IN messageProcessingModel 
globalData 
maxMessageSize 
securityModel 
securityEnginelD 
securityName 
securityLevel 
scopedPDU 
securityStateReference 


ZZZZZZZZ 


HHHHHHHH 


OUT securityParameters 
OUT wholeMsg 
OUT wholeMsgLength 

) 


4.5. Common Primitives 
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following primitive to generate a 


typically, SNMP version 

message header, admin data 

of the sending SNMP entity 

for the outgoing message 
authoritative SNMP entity 

on behalf of this principal 

for the outgoing message 
message (plaintext) payload 
reference to security state 
information from original request 
filled in by Security Module 
complete generated message 
length of the generated message 


These primitive(s) are provided by multiple Subsystems. 


4.5.1. Release State Reference Information 


All Subsystems which pass stateReference information also provide a 
primitive to release the memory that holds the referenced state 


information: 
stateRelease ( 


IN stateReference 


) 
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4.6. Scenario Diagrams 
4.6.1. Command Generator or Notification Originator 
This diagram shows how a Command Generator or Notification Originator 


application requests that a PDU be sent, and how the response is 
returned (asynchronously) to that application. 


Command Dispatcher Message Security 
Generator | Processing Model 
| | Model | 
| sendPdu | | | 
| >| | | 
| | prepareOutgoingMessage | 
A >| | 
| | generateRequestMsg 
aaa E as eres AE EA > 
| | | 
| io ES ara | 
| | | 
a SN | | 
as Po | 
| Send SNMP | | | 
| Request Message | | | 
| to Network | | 
| v | | 
| | | | 
| Receive SNMP | | | 
| Response Message | | | 
from Network | 
Lo + 
| | | 
| prepareDataElements | | 
SE ES >| | 
| processIncomingMsg | 
| A A i hee > 
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4.6.2. Scenario Diagram for a Command Responder Application 


This diagram shows how a Command Responder or Notification Receiver 
application registers for handling a pduType, how a PDU is dispatched 
to the application after an SNMP message is received, and how the 
Response is (asynchronously) send back to the network. 


Command Dispatcher Message Security 
Responder Processing Model 
Model 


| registerContextEnginelD | 


| 
| | 
o >| | | 
| <---n oan nnn nnn | Bo N | 
| | Receive SNMP | | | 
: | Message 
from Network 

eee aaa = | | 
| | | 
pas | | 
no > | 

| | processIncomingMsg 

A A a Se ee a > 
| | | 
| | o | 
| | | 
| <-------- ==" ==" ==" | | 
processPdu 

eal eens | | | 
| 


| | | 
a Poy eee eg ey ee AA A ee ee) > 
prepareResponseMsg | | 
tee aaa ean >| | 
| | generateResponseMsg | 
| p >| 
| | | 
| a | 
eeens | | 
| | | 
(pees + | | 
| Send SNMP | | | 
Message 
to Network 
| v | | 
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5. Managed Object Definitions for SNMP Management Frameworks 
SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 
IMPORTS 


MODULE-IDENTITY, OBJECT-TYPE, 
OBJECT-IDENTITY, 


snmpModules FROM SNMPv2-SMI 
TEXTUAL-CONVENTION FROM SNMPv2-TC 
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF'; 


snmpFrameworkMIB MODULE-IDENTITY 
LAST-UPDATED "2002101400002" 
ORGANIZATION "SNMPv3 Working Group" 


CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com 
Subscribe: snmpv3-request@lists.tislabs.com 
Co-Chair: Russ Mundy 
Network Associates Laboratories 
postal: 15204 Omega Drive, Suite 300 
Rockville, MD 20850-4601 
USA 
EMail: mundy@tislabs.com 
phone: +1 301-947-7107 


Co-Chair & 
Co-editor: David Harrington 
Enterasys Networks 
postal: 35 Industrial Way 
P. O. Box 5005 
Rochester, New Hampshire 03866-5005 


USA 
EMail: dbh@enterasys.com 
phone: +1 603-337-2614 


Co-editor: Randy Presuhn 
BMC Software, Inc. 


postal: 2141 North First Street 
San Jose, California 95131 
USA 

EMail: randy_presuhn@bmc.com 

phone: +1 408-546-1006 


Co-editor: Bert Wijnen 
Lucent Technologies 
postal: Schagen 33 
3461 GL Linschoten 
Netherlands 
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EMail: bwijnen@lucent.com 
phone: +31 348-680-485 


DESCRIPTION "The SNMP Management Architecture MIB 


Copyright (C) The Internet Society (2002). This 
version of this MIB module is part of RFC 3411; 
see the RFC itself for full legal notices. 


REVISION "2002101400002" =- 14 October 2002 
DESCRIPTION "Changes in this revision: 

— Updated various administrative information. 

- Corrected some typos. 

- Corrected typo in description of SnmpEngineID 
that led to range overlap for 127. 

- Changed '’255a’ to ’255t’ in definition of 
SnmpAdminString to align with current SMI. 

- Reworded 'reserved” for value zero in 
DESCRIPTION of SnmpSecurityModel. 

- The algorithm for allocating security models 
should give 256 per enterprise block, rather 
than 255. 

- The example engine ID of 'abcd” is not 
legal. Replaced with ’800002b804616263’H based 
on example enterprise 696, string ‘abc’. 

- Added clarification that engineID should 
persist across re-initializations. 

This revision published as RFC 3411. 

" 
REVISION "1999011900002" -- 19 January 1999 
DESCRIPTION "Updated editors’ addresses, fixed typos. 
Published as RFC 2571. 
" 
REVISION "1997112000002" -- 20 November 1997 
DESCRIPTION "The initial version, published in RFC 2271. 


::= { snmpModules 10 } 
-—- Textual Conventions used in the SNMP Management Architecture *** 


SnmpEngineID ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION "An SNMP engine's administratively-unique identifier. 
Objects of this type are for identification, not for 
addressing, even though it is possible that an 
address may have been used in the generation of 
a specific value. 
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The value for this object may not be all zeros or 
all 'ff'H or the empty (zero length) string. 


The initial value for this object may be configured 
via an operator console entry or via an algorithmic 
function. In the latter case, the following 
example algorithm is recommended. 


In cases where there are multiple engines on the 
same system, the use of this algorithm is NOT 
appropriate, as it would result in all of those 
engines ending up with the same ID value. 


1) The very first bit is used to indicate how the 
rest of the data is composed. 


0 — as defined by enterprise using former methods 
that existed before SNMPv3. See item 2 below. 


1 - as defined by this architecture, see item 3 
below. 


Note that this allows existing uses of the 
engineID (also known as AgentID [RFC1910]) to 
co-exist with any new uses. 


2) The snmpEngineID has a length of 12 octets. 


The first four octets are set to the binary 
equivalent of the agent's SNMP management 
private enterprise number as assigned by the 
Internet Assigned Numbers Authority (IANA). 

For example, if Acme Networks has been assigned 
{ enterprises 696 }, the first four octets would 
be assigned '000002b8'H. 


The remaining eight octets are determined via 
one or more enterprise-specific methods. Such 
methods must be designed so as to maximize the 
possibility that the value of this object will 
be unique in the agent's administrative domain. 
For example, it may be the IP address of the SNMP 
entity, or the MAC address of one of the 
interfaces, with each address suitably padded 
with random octets. If multiple methods are 
defined, then it is recommended that the first 
octet indicate the method being used and the 
remaining octets be a function of the method. 
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3) The length of the octet string varies. 


The first four octets are set to the binary 
equivalent of the agent’s SNMP management 
private enterprise number as assigned by the 
Internet Assigned Numbers Authority (IANA). 

For example, if Acme Networks has been assigned 
{ enterprises 696 }, the first four octets would 
be assigned '000002b8'H. 


The very first bit is set to 1. For example, the 
above value for Acme Networks now changes to be 
/800002b8'H. 


The fifth octet indicates how the rest (6th and 
following octets) are formatted. The values for 
the fifth octet are: 


0 - reserved, unused. 


1 - IPv4 address (4 octets) 
lowest non-special IP address 


2 - IPv6 address (16 octets) 
lowest non-special IP address 


3 - MAC address (6 octets) 
lowest IEEE MAC address, canonical 
order 

4 - Text, administratively assigned 


Maximum remaining length 27 


5 - Octets, administratively assigned 
Maximum remaining length 27 


6-127 - reserved, unused 


128-255 


as defined by the enterprise 


Maximum remaining length 27 
" 


SYNTAX OCTET STRING (SIZE(5..32)) 
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SnmpSecurityModel ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION "An identifier that uniquely identifies a 
Security Model of the Security Subsystem within 
this SNMP Management Architecture. 


The values for securityModel are allocated as 
follows: 


- The zero value does not identify any particular 
security model. 


- Values between 1 and 255, inclusive, are reserved 
for standards-track Security Models and are 
managed by the Internet Assigned Numbers Authority 
(IANA). 

- Values greater than 255 are allocated to 
enterprise-specific Security Models. An 
enterprise-specific securityModel value is defined 
to be: 


enterpriseID * 256 + security model within 
enterprise 


For example, the fourth Security Model defined by 
the enterprise whose enterpriseID is 1 would be 
259. 


This scheme for allocation of securityModel 
values allows for a maximum of 255 standards- 
based Security Models, and for a maximum of 
256 Security Models per enterprise. 


It is believed that the assignment of new 
securityModel values will be rare in practice 
because the larger the number of simultaneously 
utilized Security Models, the larger the 

chance that interoperability will suffer. 
Consequently, it is believed that such a range 
will be sufficient. In the unlikely event that 
the standards committee finds this number to be 
insufficient over time, an enterprise number 
can be allocated to obtain an additional 256 
possible values. 


Note that the most significant bit must be zero; 


hence, there are 23 bits allocated for various 
organizations to design and define non-standard 
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securityModels. This limits the ability to 
define new proprietary implementations of Security 
Models to the first 8,388,608 enterprises. 


It is worthwhile to note that, in its encoded 
form, the securityModel value will normally 
require only a single byte since, in practice, 
the leftmost bits will be zero for most messages 
and sign extension is suppressed by the encoding 
rules. 


As of this writing, there are several values 

of securityModel defined for use with SNMP or 
reserved for use with supporting MIB objects. 
They are as follows: 


O reserved for 'any” 

1 reserved for SNMPvl 

2 reserved for SNMPv2c 

3 User-Based Security Model (USM) 

" 
SYNTAX INTEGER(O .. 2147483647) 
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 

STATUS current 


DESCRIPTION "An identifier that uniquely identifies a Message 
Processing Model of the Message Processing 
Subsystem within this SNMP Management Architecture. 


The values for messageProcessingModel are 
allocated as follows: 


- Values between 0 and 255, inclusive, are 
reserved for standards-track Message Processing 
Models and are managed by the Internet Assigned 
Numbers Authority (IANA). 


- Values greater than 255 are allocated to 
enterprise-specific Message Processing Models. 
An enterprise messageProcessingModel value is 
defined to be: 


enterpriseID * 256 + 
messageProcessingModel within enterprise 


For example, the fourth Message Processing Model 
defined by the enterprise whose enterpriselD 
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is 1 would be 259. 


This scheme for allocating messageProcessingModel 
values allows for a maximum of 255 standards- 
based Message Processing Models, and for a 
maximum of 256 Message Processing Models per 
enterprise. 


It is believed that the assignment of new 
messageProcessingModel values will be rare 

in practice because the larger the number of 
simultaneously utilized Message Processing Models, 
the larger the chance that interoperability 
will suffer. It is believed that such a range 
will be sufficient. In the unlikely event that 
the standards committee finds this number to be 
insufficient over time, an enterprise number 
can be allocated to obtain an additional 256 
possible values. 


Note that the most significant bit must be zero; 
hence, there are 23 bits allocated for various 
organizations to design and define non-standard 
messageProcessingModels. This limits the ability 
to define new proprietary implementations of 
Message Processing Models to the first 8,388,608 
enterprises. 


It is worthwhile to note that, in its encoded 
form, the messageProcessingModel value will 
normally require only a single byte since, in 
practice, the leftmost bits will be zero for 
most messages and sign extension is suppressed 
by the encoding rules. 


As of this writing, there are several values of 
messageProcessingModel defined for use with SNMP. 
They are as follows: 


O reserved for SNMPvl 
1 reserved for SNMPv2c 
2 reserved for SNMPv2u and SNMPv2* 
3 reserved for SNMPv3 
" 
SYNTAX INTEGER(O .. 2147483647) 
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SnmpSecuritylLevel ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION "A Level of Security at which SNMP messages can be 
sent or with which operations are being processed; 
in particular, one of: 


noAuthNoPriv - without authentication and 
without privacy, 


authNoPriv - with authentication but 
without privacy, 
authPriv - with authentication and 


with privacy. 


These three values are ordered such that 
noAuthNoPriv is less than authNoPriv and 
authNoPriv is less than authPriv. 
" 
SYNTAX INTEGER { noAuthNoPriv (1), 
authNoPriv(2), 
authPriv (3) 
} 


SnmpAdminString ::= TEXTUAL-CONVENTION 
DISPLAY-HINT "255t" 
STATUS current 


DESCRIPTION "An octet string containing administrative 
information, preferably in human-readable form. 


To facilitate internationalization, this 
information is represented using the ISO/IEC 
IS 10646-1 character set, encoded as an octet 
string using the UTF-8 transformation format 
described in [RFC2279]. 


Since additional code points are added by 
amendments to the 10646 standard from time 
to time, implementations must be prepared to 
encounter any code point from 0x00000000 to 
OXTfffffff. Byte sequences that do not 
correspond to the valid UTF-8 encoding of a 
code point or are outside this range are 
prohibited. 


The use of control codes should be avoided. 


When it is necessary to represent a newline, 
the control code sequence CR LF should be used. 
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The use of leading or trailing white space should 
be avoided. 


For code points not directly supported by user 
interface hardware or software, an alternative 
means of entry and display, such as hexadecimal, 
may be provided. 


For information encoded in 7-bit US-ASCII, 
the UTF-8 encoding is identical to the 
US-ASCII encoding. 


UTF-8 may require multiple bytes to represent a 
single character / code point; thus the length 
of this object in octets may be different from 
the number of characters encoded. Similarly, 
size constraints refer to the number of encoded 
octets, not the number of characters represented 
by an encoding. 


Note that when this TC is used for an object that 
is used or envisioned to be used as an index, then 
a SIZE restriction MUST be specified so that the 
number of sub-identifiers for any object instance 
does not exceed the limit of 128, as defined by 
[RFC3416]. 


Note that the size of an SnmpAdminString object is 
measured in octets, not characters. 


" 


OCTET STRING (SIZE (0..255)) 


2002 


pees Administrative assignments KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpFrameworkAdmin 
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 


snmpFrameworkMIBObjects 


OBJECT IDENTIFIER 


{ snmpFrameworkMIB 2 } 


snmpFrameworkMIBConformance 
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 


= the snmpEngine Group KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 
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snmpEngineID OBJECT-TYPE 
SYNTAX SnmpEngineID 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "An SNMP engine's administratively-unique identifier. 


This information SHOULD be stored in non-volatile 
storage so that it remains constant across 
re-initializations of the SNMP engine. 


::= { snmpEngine 1 } 


snmpEngineBoots OBJECT-TYPE 


SYNTAX INTEGER (1..2147483647) 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "The number of times that the SNMP engine has 
(re-) initialized itself since snmpEnginelD 
was last configured. 


::= { snmpEngine 2 } 


snmpEngineTime OBJECT-TYPE 


SYNTAX INTEGER (0..2147483647) 
UNITS "seconds" 

MAX-ACCESS read-only 

STATUS current 


DESCRIPTION "The number of seconds since the value of 
the snmpEngineBoots object last changed. 
When incrementing this object’s value would 
cause it to exceed its maximum, 
snmpEngineBoots is incremented as if a 
re-initialization had occurred, and this 
object’s value consequently reverts to zero. 


::= { snmpEngine 3 } 


snmpEngineMaxMessageSize OBJECT-TYPE 


SYNTAX INTEGER (484..2147483647) 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "The maximum length in octets of an SNMP message 
which this SNMP engine can send or receive and 
process, determined as the minimum of the maximum 
message size values supported among all of the 
transports available to and supported by the engine. 


::= { snmpEngine 4 } 
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-- Registration Points for Authentication and Privacy Protocols ** 


snmpAuthProtocols OBJECT-IDENTITY 
STATUS current 
DESCRIPTION "Registration point for standards-track 
authentication protocols used in SNMP Management 
Frameworks. 


" 


::= [ snmpFrameworkAdmin 1 } 


snmpPrivProtocols OBJECT-IDENTITY 
STATUS current 
DESCRIPTION "Registration point for standards-track privacy 
protocols used in SNMP Management Frameworks. 


::= [ snmpFrameworkAdmin 2 } 


= Conformance information KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpFrameworkMIBCompliances 
OBJECT IDENTIFIER 
snmpFrameworkMIBGroups 
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 


{snmpFrameworkMIBConformance 1} 


-—- compliance statements 


snmpFrameworkMIBCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION "The compliance statement for SNMP engines which 
implement the SNMP Management Framework MIB. 
" 
MODULE -- this module 
MANDATORY-GROUPS { snmpEngineGroup } 


::= { snmpFrameworkMIBCompliances 1 } 
=- units of conformance 


snmpEngineGroup OBJECT-GROUP 
OBJECTS { 
snmpEnginelD, 
snmpEngineBoots, 
snmpEngineTime, 
snmpEngineMaxMessageSize 
} 
STATUS current 
DESCRIPTION "A collection of objects for identifying and 
determining the configuration and current timeliness 
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values of an SNMP engine. 


::= [ snmpFrameworkMIBGroups 1 } 
END 
6. IANA Considerations 


This document defines three number spaces administered by IANA, one 
for security models, another for message processing models, anda 
third for SnmpEngineID formats. 


6.1. Security Models 


The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are 
in the range from 0 to 255 inclusive, and are reserved for 
standards-track Security Models. If this range should in the future 
prove insufficient, an enterprise number can be allocated to obtain 
an additional 256 possible values. 


As of this writing, there are several values of securityModel defined 
for use with SNMP or reserved for use with supporting MIB objects. 
They are as follows: 


reserved for ‘any’ 

reserved for SNMPv1 

reserved for SNMPv2c 
User-Based Security Model (USM) 


WNHR OO 


6.2. Message Processing Models 


The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by 
IANA are in the range 0 to 255, inclusive. Each value uniquely 
identifies a standards-track Message Processing Model of the Message 
Processing Subsystem within the SNMP Management Architecture. 


Should this range prove insufficient in the future, an enterprise 
number may be obtained for the standards committee to get an 


additional 256 possible values. 


As of this writing, there are several values of 


messageProcessingModel defined for use with SNMP. They are as 
follows: 

O reserved for SNMPv1 

1 reserved for SNMPv2c 

2 reserved for SNMPv2u and SNMPv2* 

3 reserved for SNMPv3 
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6. 


Bi 


SnmpEngineID Formats 


The SnmpEngineID TEXTUAL-CONVENTION’s fifth octet contains a format 
identifier. The values managed by IANA are in the range 6 to 127, 
inclusive. Each value uniquely identifies a standards-track 
SnmpEngineID format. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in RFC 2028. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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9. Security Considerations 


This document describes how an implementation can include a Security 
Model to protect management messages and an Access Control Model to 
control access to management information. 


The level of security provided is determined by the specific Security 
Model implementation(s) and the specific Access Control Model 
implementation(s) used. 


Applications have access to data which is not secured. Applications 
SHOULD take reasonable steps to protect the data from disclosure. 


It is the responsibility of the purchaser of an implementation to 
ensure that: 


1) an implementation complies with the rules defined by this 
architecture, 


2) the Security and Access Control Models utilized satisfy the 
security and access control needs of the organization, 


3) the implementations of the Models and Applications comply with 
the model and application specifications, 


4) and the implementation protects configuration secrets from 
inadvertent disclosure. 


This document also contains a MIB definition module. None of the 
objects defined is writable, and the information they represent is 
not deemed to be particularly sensitive. However, if they are deemed 
sensitive in a particular environment, access to them should be 
restricted through the use of appropriately configured Security and 
Access Control models. 
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Appendix A 


A. 


Guidelines for Model Designers 


This appendix describes guidelines for designers of models which are 
expected to fit into the architecture defined in this document. 


SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 
provide trivial authentication and access control. SNMPv1 and 
SNMPv2c Frameworks can coexist with Frameworks designed according to 
this architecture, and modified versions of SNMPvl and SNMPv2c 
Frameworks could be designed to meet the requirements of this 
architecture, but this document does not provide guidelines for that 
coexistence. 


Within any subsystem model, there should be no reference to any 
specific model of another subsystem, or to data defined by a specific 
model of another subsystem. 


Transfer of data between the subsystems is deliberately described as 
a fixed set of abstract data elements and primitive functions which 
can be overloaded to satisfy the needs of multiple model definitions. 


Documents which define models to be used within this architecture 
SHOULD use the standard primitives between subsystems, possibly 
defining specific mechanisms for converting the abstract data 
elements into model-usable formats. This constraint exists to allow 
subsystem and model documents to be written recognizing common 
borders of the subsystem and model. Vendors are not constrained to 
recognize these borders in their implementations. 


The architecture defines certain standard services to be provided 
between subsystems, and the architecture defines abstract service 
interfaces to request these services. 


Each model definition for a subsystem SHOULD support the standard 
service interfaces, but whether, or how, or how well, it performs the 
service is dependent on the model definition. 


.1. Security Model Design Requirements 


.1.1. Threats 


A document describing a Security Model MUST describe how the model 
protects against the threats described under "Security Requirements 
of this Architecture", section 1.4. 
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A.1.2. Security Processing 


Received messages MUST be validated by a Model of the Security 
Subsystem. Validation includes authentication and privacy processing 
if needed, but it is explicitly allowed to send messages which do not 
require authentication or privacy. 


A received message contains a specified securityLevel to be used 
during processing. All messages requiring privacy MUST also require 
authentication. 


A Security Model specifies rules by which authentication and privacy 
are to be done. A model may define mechanisms to provide additional 
security features, but the model definition is constrained to using 
(possibly a subset of) the abstract data elements defined in this 
document for transferring data between subsystems. 


Each Security Model may allow multiple security protocols to be used 
concurrently within an implementation of the model. Each Security 
Model defines how to determine which protocol to use, given the 
securityLevel and the security parameters relevant to the message. 
Each Security Model, with its associated protocol(s) defines how the 
sending/receiving entities are identified, and how secrets are 
configured. 


Authentication and Privacy protocols supported by Security Models are 
uniquely identified using Object Identifiers. IETF standard 
protocols for authentication or privacy should have an identifier 
defined within the snmpAuthProtocols or the snmpPrivProtocols 
subtrees. Enterprise specific protocol identifiers should be defined 
within the enterprise subtree. 


For privacy, the Security Model defines what portion of the message 
is encrypted. 


The persistent data used for security should be SNMP-manageable, but 
the Security Model defines whether an instantiation of the MIB is a 
conformance requirement. 


Security Models are replaceable within the Security Subsystem. 
Multiple Security Model implementations may exist concurrently within 
an SNMP engine. The number of Security Models defined by the SNMP 
community should remain small to promote interoperability. 
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A.1.3. Validate the security-stamp in a received message 
A Message Processing Model requests that a Security Model: 
- verifies that the message has not been altered, 


- authenticates the identification of the principal for whom the 
message was generated. 


- decrypts the message if it was encrypted. 


Additional requirements may be defined by the model, and additional 
services may be provided by the model, but the model is constrained 
to use the following primitives for transferring data between 
subsystems. Implementations are not so constrained. 


A Message Processing Model uses the processIncomingMsg primitive as 
described in section 4.4.2. 


A.1.4. Security MIBs 


Each Security Model defines the MIB module(s) required for security 
processing, including any MIB module(s) required for the security 
protocol(s) supported. The MIB module(s) SHOULD be defined 
concurrently with the procedures which use the MIB module(s). The 
MIB module(s) are subject to normal access control rules. 


The mapping between the model-dependent security ID and the 
securityName MUST be able to be determined using SNMP, if the model- 
dependent MIB is instantiated and if access control policy allows 
access. 


A.1.5. Cached Security Data 


For each message received, the Security Model caches the state 
information such that a Response message can be generated using the 
same security information, even if the Local Configuration Datastore 
is altered between the time of the incoming request and the outgoing 
response. 


A Message Processing Model has the responsibility for explicitly 
releasing the cached data if such data is no longer needed. To 
enable this, an abstract securityStateReference data element is 
passed from the Security Model to the Message Processing Model. 


The cached security data may be implicitly released via the 
generation of a response, or explicitly released by using the 
stateRelease primitive, as described in section 4.5.1. 
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A.2. Message Processing Model Design Requirements 


An SNMP engine contains a Message Processing Subsystem which may 
contain multiple Message Processing Models. 


The Message Processing Model MUST always (conceptually) pass the 
complete PDU, i.e., it never forwards less than the complete list of 
varBinds. 


A.2.1. Receiving an SNMP Message from the Network 


Upon receipt of a message from the network, the Dispatcher in the 
SNMP engine determines the version of the SNMP message and interacts 
with the corresponding Message Processing Model to determine the 
abstract data elements. 


A Message Processing Model specifies the SNMP Message format it 
supports and describes how to determine the values of the abstract 
data elements (like msgID, msgMaxSize, msgFlags, 
msgSecurityParameters, securityModel, securityLevel etc). A Message 
Processing Model interacts with a Security Model to provide security 
processing for the message using the processIncomingMsg primitive, as 
described in section 4.4.2. 


A.2.2. Sending an SNMP Message to the Network 
The Dispatcher in the SNMP engine interacts with a Message Processing 
Model to prepare an outgoing message. For that it uses the following 


primitives: 


- for requests and notifications: prepareOutgoingMessage, as 
described in section 4.2.1. 


- for response messages: prepareResponseMessage, as described in 
section 4.2.2. 


A Message Processing Model, when preparing an Outgoing SNMP Message, 
interacts with a Security Model to secure the message. For that it 


uses the following primitives: 


- for requests and notifications: generateRequestMsg, as 
described in section 4.4.1. 


- for response messages: generateResponseMsg as described in 
section 4.4.3. 
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Once the SNMP message is prepared by a Message Processing Model, the 
Dispatcher sends the message to the desired address using the 
appropriate transport. 


A.3. Application Design Requirements 


Within an application, there may be an explicit binding to a specific 
SNMP message version, i.e., a specific Message Processing Model, and 

to a specific Access Control Model, but there should be no reference 

to any data defined by a specific Message Processing Model or Access 

Control Model. 


Within an application, there should be no reference to any specific 
Security Model, or any data defined by a specific Security Model. 


An application determines whether explicit or implicit access control 
should be applied to the operation, and, if access control is needed, 
which Access Control Model should be used. 


An application has the responsibility to define any MIB module(s) 
used to provide application-specific services. 


Applications interact with the SNMP engine to initiate messages, 
receive responses, receive asynchronous messages, and send responses. 


A.3.1. Applications that Initiate Messages 
Applications may request that the SNMP engine send messages 


containing SNMP commands or notifications using the sendPdu primitive 
as described in section 4.1.1. 


If it is desired that a message be sent to multiple targets, it is 
the responsibility of the application to provide the iteration. 


The SNMP engine assumes necessary access control has been applied to 
the PDU, and provides no access control services. 


The SNMP engine looks at the "expectResponse" parameter, and if a 
response is expected, then the appropriate information is cached such 
that a later response can be associated to this message, and can then 
be returned to the application. A sendPduHandle is returned to the 
application so it can later correspond the response with this message 
as well. 
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A.3.2. Applications that Receive Responses 


The SNMP engine matches the incoming response messages to outstanding 
messages sent by this SNMP engine, and forwards the response to the 
associated application using the processResponsePdu primitive, as 
described in section 4.1.4. 


A.3.3. Applications that Receive Asynchronous Messages 


When an SNMP engine receives a message that is not the response to a 
request from this SNMP engine, it must determine to which application 
the message should be given. 


An Application that wishes to receive asynchronous messages registers 
itself with the engine using the primitive registerContextEnginelD as 
described in section 4.1.5. 


An Application that wishes to stop receiving asynchronous messages 
should unregister itself with the SNMP engine using the primitive 
unregisterContextEngineID as described in section 4.1.5. 


Only one registration per combination of PDU type and contextEnginelD 
is permitted at the same time. Duplicate registrations are ignored. 
An errorIndication will be returned to the application that attempts 
to duplicate a registration. 


All asynchronously received messages containing a registered 
combination of PDU type and contextEngineID are sent to the 
application which registered to support that combination. 


The engine forwards the PDU to the registered application, using the 
processPdu primitive, as described in section 4.1.2. 


A.3.4. Applications that Send Responses 
Request operations require responses. An application sends a 


response via the returnResponsePdu primitive, as described in section 
A 3 


The contextEngineID, contextName, securityModel, securityName, 
securitylevel, and stateReference parameters are from the initial 
processPdu primitive. The PDU and statusInformation are the results 
of processing. 
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A.4. Access Control Model Design Requirements 


An Access Control Model determines whether the specified securityName 
is allowed to perform the requested operation on a specified managed 
object. The Access Control Model specifies the rules by which access 
control is determined. 


The persistent data used for access control should be manageable 
using SNMP, but the Access Control Model defines whether an 
instantiation of the MIB is a conformance requirement. 


The Access Control Model must provide the primitive isAccessAllowed. 
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